home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / misc.xsave / 000028_fdc@panix.com_Tue Dec 12 13:06:19 2006.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Path: reader2.panix.com!reader1.panix.com!panix!not-for-mail
  2. From: Frank da Cruz <fdc@panix.com>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Kermit FTP site problems
  5. Date: Tue, 12 Dec 2006 18:05:47 +0000 (UTC)
  6. Organization: PANIX Public Access Internet and UNIX, NYC
  7. Lines: 53
  8. Message-ID: <slrnentrrr.3i9.fdc@panix1.panix.com>
  9. Reply-To: fdc@columbia.edu
  10. NNTP-Posting-Host: panix1.panix.com
  11. X-Trace: reader2.panix.com 1165946747 29487 166.84.1.1 (12 Dec 2006 18:05:47 GMT)
  12. X-Complaints-To: abuse@panix.com
  13. NNTP-Posting-Date: Tue, 12 Dec 2006 18:05:47 +0000 (UTC)
  14. User-Agent: slrn/0.9.8.0 (NetBSD)
  15. Xref: panix comp.protocols.kermit.misc:15598
  16.  
  17. As many of you have reported, downloads from the Kermit FTP site are hanging
  18. and rarely complete successfully.  This started happening about 7 Dec 2006
  19. when a new release (or a patch to) Columbia's Cisco Content Switching
  20. Modules (CSMs) was installed.
  21.  
  22. Connections to the FTP server seem normal (except that sometimes you reach
  23. an empty file system, but that's a different problem).  But then a GET or an
  24. MGET, in either passive or active mode, generally results in a hung session
  25. after downloading all or most of the file.  My theory is that the TCP RST
  26. packet that is sent when the FTP server closes the data connection is not
  27. being forwarded by the CSM because it's a "runt", but who knows.  The server
  28. believes the transfer was successful and sends "226 Transfer complete." on
  29. the control connection.  So depending on how your FTP client is coded, it
  30. might accept an incomplete file as if it was complete.
  31.  
  32. Anyway the problem has been reported to Cisco, and our sysadmins (I'm not
  33. one any more) are looking into a workaround.  In the meantime, I've enabled
  34. HTTP (Web) access to all the files in the FTP archive:
  35.  
  36.   http://www.columbia.edu/kermit/ftp/
  37.  
  38. Any files downloaded with FTP from Columbia since Thursday are likely to
  39. be corrupt, and that includes files in any and all sites that mirror the
  40. Columbia's FTP site.
  41.  
  42. Watch this space for further news, and/or the Kermit Project home page:
  43.  
  44.   http://www.columbia.edu/kermit/
  45.  
  46. Meanwhile, I took advantage of the situation to add a crude but effective
  47. timeout mechanism to C-Kermit's FTP client:
  48.  
  49.   http://www.columbia.edu/kermit/ckdaily.html
  50.  
  51. So far it works only for GET and MGET, not for PUT or MPUT, and not for
  52. operations on the control connection like DIR, but at least now you can
  53. time out of hung GETs:
  54.  
  55.   set ftp timeout 20
  56.   get x.tar.gz
  57.  
  58. The timeout value is in seconds.  It applies not to the whole tranfer, but
  59. to each attempt to read from the data connection, kind of like Kermit
  60. protocol per-packet timeouts.
  61.  
  62. This feature works in consort with SET FTP ERROR-ACTION and SET FILE
  63. INCOMPLETE, so you can decide what should happen if there is a timeout --
  64. keep the incomplete file or delete it; go on to the next one (if MGET'ing)
  65. or stop dead.  Remember, you are downloading in binary mode and the file
  66. is incomplete, in most cases (depending on the server) you can REGET it
  67. rather than starting over.
  68.  
  69. - Frank